LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262788

Failed test cases in LAVA job 262788 (SoC: monaco-evk).

  Case 1: ** Probe_Failure_Check — WiFi Driver Probe Failure (ath11k_pci)

1. Failed case: ** Probe_Failure_Check — WiFi Driver Probe Failure (ath11k_pci)
2. Root cause: ** WiFi driver probe failed with -ETIMEDOUT (-110) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs image on monaco-evk (iq-8275-evk). The MHI subsystem timed out waiting for firmware load, causing the ath11k_pci driver probe to fail. This is a pre-existing infrastructure issue specific to the monaco-evk platform and is NOT introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 (which only changes CPUidle governor configuration).
3. Possible fix: Add the missing WiFi firmware files to the monaco-evk rootfs image. Specifically, package ath11k/WCN6855/hw2.1/nfa765/amss.bin and related firmware files in the build artifact. Alternatively, if WiFi is not required for monaco-evk validation, suppress this test case for this platform or mark it as expected-fail until firmware is available.
4. Detail analysis attachment: failed_case_job262788_1_detailed.md

  Case 2: WiFi_Firmware_Driver — ath11k_pci probe failure with MHI timeout

1. Failed case: WiFi_Firmware_Driver — ath11k_pci probe failure with MHI timeout
2. Root cause: ath11k_pci driver probe failed with -110 (ETIMEDOUT) during MHI power-up sequence after firmware load failure. The PR changes the CPUidle governor from MENU to TEO, which may alter CPU idle state entry/exit timing and affect time-sensitive MHI bus initialization and firmware handshake on the monaco-evk platform with WCN6855 WiFi hardware.
3. Possible fix: Revert the CPUidle governor change (restore CONFIG_CPU_IDLE_GOV_MENU=y) and retest on monaco-evk to confirm whether the TEO governor introduces timing regressions in MHI/ath11k initialization. If the issue persists after revert, investigate MHI firmware availability and bus timing constraints specific to monaco-evk. If TEO is required for performance, add platform-specific tuning or increase MHI timeout values for monaco-evk.
4. Detail analysis attachment: failed_case_job262788_2_detailed.md

  Case 3: WiFi_OnOff

1. Failed case: WiFi_OnOff
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the monaco-evk Yocto image recipe (likely in linux-firmware-qcom-ath11k package or equivalent). Verify the firmware file exists in the upstream linux-firmware repository or Qualcomm firmware drop for WCN6855 hw2.1 nfa765 variant, then include it in the rootfs build manifest.
4. Detail analysis attachment: failed_case_job262788_3_detailed.md

  Case 4: Driver Probe Failure — ath11k_pci WiFi driver

1. Failed case: Driver Probe Failure — ath11k_pci WiFi driver
2. Root cause: ath11k_pci driver probe failed with -ETIMEDOUT (-110) during MHI power-up because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs. This is a pre-existing infrastructure/firmware packaging issue, not introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 which only changes the CPUidle governor configuration.
3. Possible fix: Add the missing ath11k firmware files (specifically ath11k/WCN6855/hw2.1/nfa765/amss.bin and related WCN6855 firmware) to the rootfs image used by the monaco-evk LAVA job. The firmware should be packaged in /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ directory. This is a build/packaging fix, not a kernel code fix.
4. Detail analysis attachment: failed_case_job262788_4_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262789

Failed test cases in LAVA job 262789 (SoC: shikra-iqs-evk).

  Case 1: GIC (Test Infrastructure Bug)

1. Failed case: GIC (Test Infrastructure Bug)
2. Root cause: The GIC test script (run.sh line 75) is hardcoded to validate timer interrupt increments for CPUs 0-7, but the shikra-iqs-evk platform has only 4 CPUs (0-3). When the script attempts to parse /proc/interrupts for non-existent CPUs 4-7, it incorrectly reads non-numeric fields ("GICv3", "Level", "arch_timer") from the interrupt line and treats them as interrupt counts, causing bash integer comparison errors and false test failures.
3. Possible fix: Update the GIC test script to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding CPU count assumptions. The script should iterate only over CPUs that actually exist on the target platform.
4. Detail analysis attachment: failed_case_job262789_1_detailed.md

  Case 2: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Pre-existing platform-specific probe failures on shikra-iqs-evk unrelated to PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 (CPUidle governor config change); failures include missing firmware files (regulatory.db, ccg_secondary.cyacd2), TPM SPI timeout (-110), and audio subsystem deferred probes (va_macro mclk clock, snd-sc8280xp DAI name) that are board/firmware configuration issues, not kernel regressions introduced by switching from MENU to TEO CPUidle governor.
3. Possible fix: Mark Probe_Failure_Check as a known benign failure for shikra-iqs-evk baseline or exclude these specific probe failures from the test criteria; the PR changes only CPUidle governor selection and cannot cause firmware load failures, I2C device probe failures, or audio clock/DAI configuration issues — these are pre-existing board/firmware/DT configuration gaps on this platform.
4. Detail analysis attachment: failed_case_job262789_2_detailed.md

  Case 3: PCIe — QPS615 Firmware Missing

1. Failed case: PCIe — QPS615 Firmware Missing
2. Root cause: The PCIe test failed because the QPS615 PCIe switch firmware file TC956X_Firmware_PCIeBridge.bin is not present in the rootfs firmware directories, and the corresponding kernel driver module tc956x_pcie_eth is not built or installed for this kernel. This is a pre-existing infrastructure/build configuration issue, not introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 (which only changes CPUidle governor config).
3. Possible fix: Add the QPS615 firmware file TC956X_Firmware_PCIeBridge.bin to the rootfs firmware directories (typically /lib/firmware/) and ensure the tc956x_pcie_eth kernel module is built and included in the image. This is a build/image configuration issue that requires updating the Yocto/build recipe to include the QPS615 firmware package and enable the TC956X PCIe Ethernet driver in the kernel config.
4. Detail analysis attachment: failed_case_job262789_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Configure the USB ports to host mode by: (1) checking Type-C connector orientation and ensuring host-mode cable is used, (2) verifying device tree USB role configuration for shikra-iqs-evk specifies host or dual-role with host default, (3) checking hardware jumpers/straps if applicable, or (4) using USB role switch sysfs interface to manually switch to host mode before running the test. If this is a known test environment limitation, mark USBHost as SKIP for shikra-iqs-evk in gadget-only configurations.
4. Detail analysis attachment: failed_case_job262789_4_detailed.md

  Case 5: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is not a kernel bug or PR-introduced regression (PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 only changes CPUidle governor configuration). To enable KVM testing on shikra-iqs-evk, either: (1) boot without the Gunyah hypervisor (use a non-virtualized boot configuration), or (2) exclude KVM tests from the CI test suite for Gunyah-enabled builds, as KVM and Gunyah are mutually exclusive at the platform level.
4. Detail analysis attachment: failed_case_job262789_5_detailed.md

  Case 6: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** Shikra IQS EVK bootloader boots the kernel at EL1 (Exception Level 1) instead of EL2 (Hypervisor mode), preventing KVM initialization; KVM reports "HYP mode not available" at boot (line 3422: "kvm [1]: HYP mode not available"), causing /dev/kvm device node to never be created, which the test correctly detects and fails.
3. Possible fix: This is a pre-existing platform configuration issue, NOT a regression introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 (which only changes CPUIdle governor). To enable KVM on Shikra IQS EVK: (1) Configure the bootloader (ABL/UEFI) to boot the kernel at EL2 instead of EL1, OR (2) Disable CONFIG_KVM in the kernel configuration for this platform if virtualization is not required, OR (3) Mark KVM tests as expected-to-fail for Shikra IQS EVK in the LAVA test suite until bootloader configuration is updated.
4. Detail analysis attachment: failed_case_job262789_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is expected behavior on Shikra IQS EVK when Gunyah hypervisor is enabled in firmware. To enable KVM testing: (1) disable Gunyah in the bootloader/firmware configuration, or (2) use a different test platform without a pre-installed hypervisor, or (3) mark KVM tests as "expected skip" for Gunyah-enabled platforms in the CI test matrix. No kernel code change required — this is a test environment configuration issue.
4. Detail analysis attachment: failed_case_job262789_7_detailed.md

  Case 8: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM infrastructure test failed because HYP (Hypervisor) mode is not available on the shikra-iqs-evk platform — kernel message at boot: "kvm [1]: HYP mode not available". CONFIG_KVM is enabled but /dev/kvm device node is not created because the hardware/firmware does not support EL2 virtualization.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR (changing CPUIdle governor from MENU to TEO) does not affect KVM/virtualization. Mark KVM_Infra as expected-fail for shikra-iqs-evk in the LAVA test definition, or exclude KVM tests from this platform's CI suite until EL2 support is enabled in the firmware/bootloader.
4. Detail analysis attachment: failed_case_job262789_8_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262790

Failed test cases in LAVA job 262790 (SoC: qcs9100-ride).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: No action required**. This failure should be suppressed per LAVA Known Benign Failure Suppression Rule 2 (WiFi firmware false positive when WiFi functional tests pass). If the test framework needs updating, modify the Probe_Failure_Check test to exclude regulatory.db firmware load failures when WiFi functional tests pass, or add regulatory.db to the rootfs if strict compliance is desired (though it is not functionally required).
4. Detail analysis attachment: failed_case_job262790_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Update the smmu test's critical device list to be platform-aware: for qcs9100-ride, check for iris_non_pixel.0 and iris_pixel.0 instead of aa00000.video-codec. Alternatively, make the video codec check optional or conditional based on device tree presence.
4. Detail analysis attachment: failed_case_job262790_2_detailed.md

  Case 3: KVM_Driver — Platform Virtualization Not Supported

1. Failed case: KVM_Driver — Platform Virtualization Not Supported
2. Root cause: The qcs9100-ride (LeMans Ride Rev3) platform does not support ARM virtualization extensions (EL2/HYP mode). Kernel message at boot: kvm [1]: HYP mode not available. CONFIG_KVM and CONFIG_VIRTUALIZATION are enabled in the kernel config, but the hardware does not provide the necessary virtualization support, preventing /dev/kvm device node creation.
3. Possible fix: This is not a kernel bug or PR-introduced regression — it is a hardware platform limitation. The KVM_Driver test should be skipped on qcs9100-ride targets that lack virtualization support. Add platform detection to the LAVA test definition to skip KVM tests on non-virtualization-capable SoCs (check for /dev/kvm presence or parse dmesg | grep "HYP mode" before running KVM tests). Alternatively, update the CI job definition to exclude KVM tests from the qcs9100-ride test suite.
4. Detail analysis attachment: failed_case_job262790_3_detailed.md

  Case 4: KVM_EL2_DTB — Platform KVM Initialization Failure

1. Failed case: KVM_EL2_DTB — Platform KVM Initialization Failure
2. Root cause: The qcs9100-ride platform does not support EL2 (hypervisor exception level); kernel message "kvm [1]: HYP mode not available" at boot time (4.015916s) indicates the hardware/firmware boots at EL1 without EL2 support, preventing KVM from initializing and creating /dev/kvm.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. The PR changes only CPUidle governor config (CONFIG_CPU_IDLE_GOV_MENU → CONFIG_CPU_IDLE_GOV_TEO), which is unrelated to virtualization. To resolve: (1) exclude KVM tests from qcs9100-ride CI runs, or (2) configure the platform firmware/bootloader to boot at EL2 if the hardware supports it, or (3) use a different platform that supports EL2 for KVM testing.
4. Detail analysis attachment: failed_case_job262790_4_detailed.md

  Case 5: KVM Infrastructure Test — /dev/kvm unavailable (HYP mode not available)

1. Failed case: KVM Infrastructure Test — /dev/kvm unavailable (HYP mode not available)
2. Root cause: KVM initialization failed because the qcs9100-ride platform is running under the Gunyah hypervisor which has exclusive control of EL2/HYP mode. The kernel log shows kvm [1]: HYP mode not available at boot, preventing /dev/kvm device node creation. This is a platform configuration constraint, not a kernel bug or PR-introduced regression.
3. Possible fix: This is expected behavior on qcs9100-ride when running under Gunyah hypervisor. Either: (1) skip KVM tests on this platform in CI (recommended — add platform exclusion rule for KVM test suite on qcs9100-ride), or (2) if KVM support is required, reconfigure the boot flow to run Linux at EL2 without Gunyah (requires bootloader/firmware changes and is not recommended for this platform's intended use case).
4. Detail analysis attachment: failed_case_job262790_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Platform hardware limitation — QCS9100 (LeMans) Ride Rev3 does not support EL2 (Hypervisor mode), preventing KVM initialization. Kernel reports "kvm [1]: HYP mode not available" at boot, causing /dev/kvm device node creation to fail.
3. Possible fix: Mark KVM tests as "skip" or "not applicable" for qcs9100-ride platform in the LAVA test job definition, as this SoC does not support virtualization extensions. Alternatively, exclude KVM test suite from qcs9100-ride CI runs.
4. Detail analysis attachment: failed_case_job262790_6_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262791

Failed test cases in LAVA job 262791 (SoC: qcs615-ride).

  Case 1: Probe_Failure_Check (False Positive — Pre-existing Infrastructure Issue)

1. Failed case: Probe_Failure_Check (False Positive — Pre-existing Infrastructure Issue)
2. Root cause: The Probe_Failure_Check test flagged a benign firmware load failure for regulatory.db (error -2, file not found) during cfg80211 wireless regulatory subsystem initialization. This is a pre-existing condition unrelated to the PR, which only changes CPUidle governor configuration. WiFi hardware (ath11k_pci qca6698aq) initialized successfully despite the missing regulatory.db file, indicating the failure is non-functional.
3. Possible fix: Suppress this specific regulatory.db firmware load failure in the Probe_Failure_Check test logic, as it is a known benign condition on qcs615-ride when WiFi functional tests pass. Alternatively, add the wireless-regdb package to the rootfs to provide /lib/firmware/regulatory.db, though this is not required for WiFi functionality on this platform.
4. Detail analysis attachment: failed_case_job262791_1_detailed.md

  Case 2: smmu (Test Infrastructure Issue — Incorrect Device Expectation)

1. Failed case: smmu (Test Infrastructure Issue — Incorrect Device Expectation)
2. Root cause: The smmu test expects platform devices named aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder to be attached to IOMMU groups, but the Venus video codec driver (using non-legacy binding) creates video4linux character devices (/dev/videoX) instead of separate platform devices. The parent device aa00000.video-codec is correctly attached to IOMMU group 7. This is a test design issue, not a kernel regression. The PR changes only CPUidle governor configuration (CONFIG_CPU_IDLE_GOV_MENU → CONFIG_CPU_IDLE_GOV_TEO) and has no relationship to IOMMU or video codec functionality.
3. Possible fix: Update the smmu test script to remove the check for video-decoder and video-encoder as separate platform devices, or modify it to verify that the parent video-codec device is attached to an IOMMU group (which it is). The test should not expect child platform devices for Venus video codec when using the modern (non-legacy) device tree binding. This is a test infrastructure fix, not a kernel fix. The PR can proceed as the failure is unrelated to the CPUidle governor change.
4. Detail analysis attachment: failed_case_job262791_2_detailed.md

  Case 3: KVM_Driver (Platform Configuration Issue — Not a Regression)

1. Failed case: KVM_Driver (Platform Configuration Issue — Not a Regression)
2. Root cause: QCS615 Ride platform is configured with Gunyah hypervisor running at EL2; KVM requires exclusive EL2 access and cannot initialize when another hypervisor is present, resulting in "HYP mode not available" message and missing /dev/kvm device node.
3. Possible fix: This is expected platform behavior, not a bug. To enable KVM testing on QCS615: (1) disable Gunyah hypervisor in bootloader/firmware configuration, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms, or (3) use a different platform without Gunyah for KVM validation.
4. Detail analysis attachment: failed_case_job262791_3_detailed.md

  Case 4: KVM Device Node Missing — /dev/kvm not available (KVM initialization failure)

1. Failed case: KVM Device Node Missing — /dev/kvm not available (KVM initialization failure)
2. Root cause: KVM failed to initialize because the platform is running under the Gunyah hypervisor in EL2, preventing KVM from accessing HYP mode. The kernel message "kvm [1]: HYP mode not available" at boot indicates KVM detected it cannot operate because EL2 is already occupied by the Gunyah hypervisor (version gunyah-cdfb73831). This is a platform configuration issue, not a kernel regression.
3. Possible fix: This is expected behavior on qcs615-ride when Gunyah hypervisor is active. The KVM tests should be skipped on platforms running under a hypervisor. Add a pre-test check to detect hypervisor presence (check for "Hypervisor" in dmesg or /proc/cpuinfo) and skip KVM tests when a hypervisor is detected, or exclude qcs615-ride from KVM test matrix when Gunyah is enabled.
4. Detail analysis attachment: failed_case_job262791_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on QCS615-Ride because the platform boots under Gunyah hypervisor at EL2, preventing KVM from accessing HYP mode (kernel message: "kvm [1]: HYP mode not available").
3. Possible fix: This is a platform limitation, not a PR-introduced regression. The PR changes CPUidle governor (MENU→TEO) and is unrelated to KVM. Mark KVM tests as expected-fail for QCS615-Ride or exclude them from the test suite for hypervisor-enabled platforms.
4. Detail analysis attachment: failed_case_job262791_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on QCS615 because EL2 (Hypervisor mode) is not available on this platform — kernel log shows kvm [1]: HYP mode not available at boot, preventing /dev/kvm device node creation.
3. Possible fix: Mark KVM tests as expected-fail or skip them on QCS615 platform in the LAVA test definition, as this SoC does not support virtualization (no EL2 access). This is a hardware limitation, not a kernel bug.
4. Detail analysis attachment: failed_case_job262791_6_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262792

Failed test cases in LAVA job 262792 (SoC: hamoa-evk).

  Case 1: Probe_Failure_Check (driver probe failures - benign pre-existing issues)

1. Failed case: Probe_Failure_Check (driver probe failures - benign pre-existing issues)
2. Root cause: Two benign probe failures detected: (1) qcom_qseecom_uefisecapp probe failed with -EBUSY (error -16) due to TrustZone secure app resource unavailability - this is a known optional component on hamoa-evk; (2) regulatory.db firmware load failed with -ENOENT (error -2) because the file is not present in the rootfs - cfg80211 falls back to built-in regulatory rules. Neither failure is introduced by the PR (CPUidle governor config change) and both are pre-existing platform characteristics.
3. Possible fix: Mark this test case as expected-fail for hamoa-evk platform, or update the Probe_Failure_Check test to exclude known benign probe failures (qcom_qseecom_uefisecapp -EBUSY, regulatory.db -ENOENT) from the failure criteria. These are not regressions and do not indicate kernel instability - 56 other tests passed successfully.
4. Detail analysis attachment: failed_case_job262792_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The video codec device (aa00000.video-codec) is not attached to any IOMMU group on the hamoa-evk platform. This is a pre-existing platform configuration issue where the device tree does not specify IOMMU bindings for the video codec, or the video codec driver has not probed. The SMMU subsystem itself is functioning correctly with no faults or errors.
3. Possible fix: This is not a PR-introduced regression (PR only changes CPUidle governor). Verify the device tree for hamoa-evk includes iommus property for the video-codec@aa00000 node. If the property exists, check if the video codec driver (venus/iris) is enabled in the kernel config and successfully probing. If this device is intentionally not IOMMU-protected on hamoa-evk, update the test expectations to exclude it from the critical masters list for this platform.
4. Detail analysis attachment: failed_case_job262792_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Hamoa-evk platform boots Linux at EL1 under Gunyah hypervisor (gunyah-mobile-1f99e07c2), preventing KVM from accessing EL2 hypervisor mode required for virtualization; kernel reports "HYP mode not available" at boot.
3. Possible fix: Reconfigure the platform firmware/bootloader to boot Linux directly at EL2 without the Gunyah hypervisor, or use a different boot configuration (e.g., EFI selection) that provides EL2 access to Linux; alternatively, mark KVM tests as expected-fail for Gunyah-based boot configurations on hamoa-evk.
4. Detail analysis attachment: failed_case_job262792_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM requires the CPU to run at EL2 (Hypervisor exception level), but the Hamoa IoT EVK platform boots Linux at EL1 (kernel exception level), as confirmed by the kernel message "CPU: All CPU(s) started at EL1" and "kvm [1]: HYP mode not available".
3. Possible fix: This is a pre-existing platform configuration limitation, not a PR-introduced regression. The PR only changes CPUidle governor (CONFIG_CPU_IDLE_GOV_MENU → CONFIG_CPU_IDLE_GOV_TEO) and has no impact on virtualization capabilities. To enable KVM on this platform, the bootloader/firmware must be configured to boot Linux at EL2, or the test suite should skip KVM tests on platforms that do not support EL2 boot.
4. Detail analysis attachment: failed_case_job262792_4_detailed.md

  Case 5: KVM_Infra — Platform Configuration Limitation (Not a Genuine Failure)

1. Failed case: KVM_Infra — Platform Configuration Limitation (Not a Genuine Failure)
2. Root cause: Hamoa-evk platform runs Gunyah hypervisor (gunyah-mobile-1f99e07c2) at EL2, which owns the hypervisor privilege level. Linux kernel runs at EL1 and cannot access HYP mode, causing KVM initialization to report "HYP mode not available" at boot (line 3374: kvm [1]: HYP mode not available). CONFIG_KVM is enabled but /dev/kvm device node is not created because the platform does not support nested virtualization.
3. Possible fix: This is a platform hardware/firmware configuration, not a kernel bug or PR-introduced regression. The PR (CPUidle governor change) is unrelated to KVM. To enable KVM on Hamoa: (1) verify if the platform supports nested virtualization under Gunyah, (2) if not supported, mark KVM tests as "skip" for Hamoa in the LAVA test suite configuration, or (3) disable CONFIG_KVM in the kernel config for Hamoa-specific builds. No kernel code fix is required.
4. Detail analysis attachment: failed_case_job262792_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: KVM tests fail because hamoa-evk hardware does not support HYP mode (ARM virtualization extensions). Kernel message at boot: "kvm [1]: HYP mode not available" indicates the platform lacks EL2 hypervisor support required for /dev/kvm device creation. CONFIG_KVM is enabled in kernel config but cannot initialize without hardware virtualization capability.
3. Possible fix: Exclude KVM test suite from hamoa-evk LAVA job definition, as this platform does not support hardware virtualization. Add platform capability check to LAVA job template to skip virtualization tests on non-HYP-capable boards. This is not a kernel regression — the PR changes only CPUIdle governor config (qcom.config) and does not affect virtualization support.
4. Detail analysis attachment: failed_case_job262792_6_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262793

Failed test cases in LAVA job 262793 (SoC: qcs6490-rb3gen2).

  Case 1: cdsp_remoteproc

1. Failed case: cdsp_remoteproc
2. Root cause: CDSP remoteproc crashed during boot with MMU fault (SMMU translation fault at IOVA 0xc00c6000) followed by watchdog timeout, leaving the subsystem in offline state. The crash occurred immediately after firmware load began, indicating a memory access violation by the CDSP firmware during initialization. This is a pre-existing platform/firmware issue unrelated to the PR's CPUIdle governor change (CONFIG_CPU_IDLE_GOV_MENU → CONFIG_CPU_IDLE_GOV_TEO), as the crash happens during early boot before CPUIdle governor selection would affect remoteproc operation.
3. Possible fix: This is a pre-existing CDSP firmware or platform integration issue on qcs6490-rb3gen2, not introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320. The PR only changes the CPUIdle governor configuration and does not touch remoteproc, SMMU, or CDSP-related code. Recommend: (1) Verify CDSP firmware version matches the kernel build; (2) Check if CDSP reserved memory regions in device tree are correctly configured; (3) Investigate SMMU context bank 15 (SID=0x15a0) mapping for CDSP; (4) Re-run the test on a known-good baseline without the PR to confirm this failure exists independently. If the baseline also fails, this is a board/firmware issue requiring platform team investigation, not a PR blocker.
4. Detail analysis attachment: failed_case_job262793_1_detailed.md

  Case 2: GIC Test Script Bug — Offline CPU Handling

1. Failed case: GIC Test Script Bug — Offline CPU Handling
2. Root cause: The GIC test script incorrectly assumes all possible CPUs (0-7) are online and attempts to parse timer interrupt counts for offline CPUs 6-7 from /proc/interrupts, which only contains columns for online CPUs (0-5), causing a bash integer comparison error when it encounters "GICv3" instead of a number.
3. Possible fix: Update the GIC test script to iterate only over online CPUs (read from /sys/devices/system/cpu/online) instead of possible CPUs, or add a check to skip offline CPUs before attempting to parse their interrupt counts.
4. Detail analysis attachment: failed_case_job262793_2_detailed.md

  Case 3: ** Probe_Failure_Check (benign firmware load failures)

1. Failed case: ** Probe_Failure_Check (benign firmware load failures)
2. Root cause: ** Two firmware files are missing from the rootfs image: regulatory.db (WiFi regulatory database) and renesas_usb_fw.mem (Renesas USB3 controller firmware). Both failures are benign: WiFi functional tests pass (regulatory.db is optional, driver uses built-in rules), and the Renesas USB controller is an optional PCIe add-on not required for test suite functionality.
3. Possible fix: Suppress these two known-benign firmware load failures in the Probe_Failure_Check test logic by adding exceptions for: (1) regulatory.db when WiFi_OnOff test passes, and (2) renesas_usb_fw.mem for optional PCIe USB controllers. Alternatively, package the firmware files in the rootfs if the devices are intended to be used.
4. Detail analysis attachment: failed_case_job262793_3_detailed.md

  Case 4: Freq_Scaling

1. Failed case: Freq_Scaling
2. Root cause: Test infrastructure issue — the Freq_Scaling test script reports FAIL despite all individual validation checks (CONFIG_CPU_FREQ, CONFIG_CPU_FREQ_GOV_SCHEDUTIL, CONFIG_CPU_FREQ_GOV_PERFORMANCE, and cpufreq interfaces for all 6 CPUs) passing successfully. The shell command "+ true" in the test output indicates the test script used error suppression (likely || true), suggesting an uncaught failure in test logic rather than a genuine kernel regression. The PR changes only the CPUidle governor (MENU→TEO), which does not affect cpufreq functionality, and the separate CPUFreq_Validation test passed, confirming frequency scaling works correctly.
3. Possible fix: Review and update the Freq_Scaling test script in the CI test suite to identify why it reports FAIL when all validation checks pass. The test may have hardcoded expectations about CPUidle governor configuration (expecting MENU) or may have a logic error in its result aggregation. As a workaround, re-run the LAVA job to confirm reproducibility, and verify that the CPUFreq_Validation test (which actually exercises frequency scaling) continues to pass.
4. Detail analysis attachment: failed_case_job262793_4_detailed.md

  Case 5: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test runner infrastructure issue — the test definition was marked as failed with "Marking unfinished test run as failed" despite all executed tests completing and reporting results correctly; the test runner's completion logic detected an inconsistent state after result_parse.sh listed previously-executed test result files (CPU_affinity.res, Freq_Scaling.res) before exiting normally.
3. Possible fix: Re-trigger the LAVA job to confirm this is a transient LAVA infrastructure issue; if the failure recurs, investigate the LAVA test definition's test list and result collection logic to ensure all expected tests are properly registered and their completion is correctly tracked by the test runner.
4. Detail analysis attachment: failed_case_job262793_5_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262794

Failed test cases in LAVA job 262794 (SoC: lemans-evk).

  Case 1: Probe_Failure_Check — Known Benign Firmware Load False Positives (Suppressed)

1. Failed case: Probe_Failure_Check — Known Benign Firmware Load False Positives (Suppressed)
2. Root cause: The test detected three firmware load errors during early boot (regulatory.db, wcnhpbtfw21.tlv, hpbtfw21.tlv) that are known benign false positives. The Bluetooth firmware files are not present in the initial firmware search paths but are successfully loaded later via fallback mechanisms. The BT_ON_OFF functional test passed, confirming Bluetooth is fully operational (adapter hci0 UP RUNNING, power cycling successful). The regulatory.db error is also benign as regulatory functionality works via built-in database.
3. Possible fix: Suppress this failure per LAVA Known Benign Failure Suppression Rule 3. The Probe_Failure_Check test should exclude these specific firmware load patterns when the corresponding functional tests (BT_ON_OFF) pass, or the test's pattern matching should be refined to ignore -ENOENT (-2) errors for optional firmware files that have fallback mechanisms. No kernel or PR changes required — this is a test infrastructure false positive unrelated to the PR (CPUidle governor config change).
4. Detail analysis attachment: failed_case_job262794_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec at address 0xaa00000 is not attached to any IOMMU group because the video codec driver (qcom-venus) is not probing on lemans-evk (SA8775P/IQ-9075). The device exists in the device tree (test checks for it) but no driver probe messages appear in the kernel log, and the device is absent from /sys/kernel/iommu_groups/*/devices/. This is a pre-existing platform limitation on lemans-evk, not introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 which only changes CPUidle governor configuration.
3. Possible fix: This is a known platform limitation on lemans-evk where the video codec driver is not enabled or not probing. The test expectation should be updated to exclude video codec from critical master checks on lemans-evk, or the video codec driver support should be enabled for this platform. This failure is unrelated to the PR changes (CPUidle governor switch from menu to teo) and should not block the PR.
4. Detail analysis attachment: failed_case_job262794_2_detailed.md

  Case 3: LAVA Test Infrastructure Issue — Test Definition Marked Incomplete

1. Failed case: LAVA Test Infrastructure Issue — Test Definition Marked Incomplete
2. Root cause: LAVA test framework marked the test definition 0_qcom-next-ci-premerge-tests as failed with "Marking unfinished test run as failed" after the test runner exited normally with <LAVA_TEST_RUNNER EXIT>. The kernel booted successfully and 30 individual test cases passed, but 2 tests failed (Probe_Failure_Check with benign firmware load errors, and smmu with Video codec aa00000.video-codec missing IOMMU group attachment). The test definition failure is a LAVA infrastructure issue where the test runner completed but LAVA detected the test suite as incomplete, likely due to a mismatch between expected and executed tests or improper test definition exit handling.
3. Possible fix: This is not a kernel regression introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 (CPUidle governor config change). The smmu test failure (Video codec missing IOMMU group) is a pre-existing platform issue unrelated to the CPUidle governor change. The Probe_Failure_Check failure is benign (firmware load fallback behavior). The LAVA "unfinished test run" marking is a test infrastructure issue. Re-trigger the CI job to verify if this is transient. If it recurs, investigate the LAVA test definition for proper exit handling and verify the test runner configuration matches the expected test list in the job definition.
4. Detail analysis attachment: failed_case_job262794_3_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262795

Failed test cases in LAVA job 262795 (SoC: purwa-evk).

  Case 1: ** Probe_Failure_Check — Pre-existing Platform Configuration Issues (Non-Genuine Failure)

1. Failed case: ** Probe_Failure_Check — Pre-existing Platform Configuration Issues (Non-Genuine Failure)
2. Root cause: ** QSEE secure app resource conflict or unavailable in current boot mode
3. Possible fix: Mark Probe_Failure_Check as a known false positive for purwa-evk platform. Update the test to suppress these 4 specific benign probe failures as platform-expected: (1) qcom_qseecom_uefisecapp error -16 (alternative efivars path functional), (2-3) qcom-pcie 1bf8000/1bd0000 error -61 (unpopulated controllers, 1c08000 controller functional), (4) regulatory.db error -2 (built-in X.509 certs used, wireless fully functional). These failures are not regressions and do not indicate kernel issues introduced by PR1320 (CPUidle governor config change).
4. Detail analysis attachment: failed_case_job262795_1_detailed.md

  Case 2: smmu (Device Configuration Issue — IOMMU Group Attachment Missing)

1. Failed case: smmu (Device Configuration Issue — IOMMU Group Attachment Missing)
2. Root cause: The video codec device (aa00000.video-codec) on purwa-evk is missing IOMMU group attachment, indicating either a missing iommus property in the device tree node or the video codec driver not probing. This is a pre-existing platform configuration issue, NOT introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 (which only changes CPUIdle governor from MENU to TEO).
3. Possible fix: Add or correct the iommus property in the purwa-evk video codec device tree node (likely in arch/arm64/boot/dts/qcom/purwa-*.dts) to reference the appropriate SMMU. Verify the video codec driver is enabled in kernel config. This is a platform-specific DT fix unrelated to the PR changes.
4. Detail analysis attachment: failed_case_job262795_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: Platform does not support EL2 (hypervisor mode) — bootloader boots kernel at EL1, preventing KVM initialization. Kernel message: "kvm [1]: HYP mode not available" at boot time.
3. Possible fix: This is a platform/firmware limitation on Purwa IoT EVK. Either: (1) Update bootloader/firmware to boot kernel at EL2, or (2) Mark KVM tests as expected-to-skip for this platform in CI configuration, or (3) Disable CONFIG_KVM for this platform if virtualization is not a supported feature.
4. Detail analysis attachment: failed_case_job262795_3_detailed.md

  Case 4: KVM_EL2_DTB (Platform Limitation - Nested Virtualization Not Available)

1. Failed case: KVM_EL2_DTB (Platform Limitation - Nested Virtualization Not Available)
2. Root cause: System is running as a guest VM under Gunyah hypervisor (version gunyah-mobile-1f99e07c2), which does not expose EL2/HYP mode to the guest kernel. KVM requires EL2 access to initialize and create /dev/kvm. The kernel correctly detects "HYP mode not available" and does not initialize KVM. This is expected behavior on virtualized platforms without nested virtualization support.
3. Possible fix: Modify the LAVA test definition to detect hypervisor presence (check for "Hypervisor cold boot" in dmesg or /sys/hypervisor/ directory) and skip KVM tests with result=SKIP (not FAIL) when running under a hypervisor. Alternatively, enable nested virtualization in the Gunyah hypervisor configuration for purwa-evk if KVM testing is required on this platform.
4. Detail analysis attachment: failed_case_job262795_4_detailed.md

  Case 5: ** KVM Infrastructure Unavailable — Platform Architecture Constraint

1. Failed case: ** KVM Infrastructure Unavailable — Platform Architecture Constraint
2. Root cause: ** KVM cannot initialize on purwa-evk because the platform runs under Gunyah hypervisor (EL2), which does not expose nested virtualization. Linux kernel detects kvm [1]: HYP mode not available at boot (line 3149 in log). CONFIG_KVM is enabled but /dev/kvm device node is never created because kvm_init() fails during early boot.
3. Possible fix: Disable KVM tests for purwa-evk platform in the LAVA test suite configuration, or add a platform-specific test skip condition. KVM cannot be supported on this SoC without nested virtualization support in the Gunyah hypervisor. If KVM support is required, the platform must boot without Gunyah (native Linux on bare metal with HYP mode accessible).
4. Detail analysis attachment: failed_case_job262795_5_detailed.md

  Case 6: ** KVM_Infra

1. Failed case: ** KVM_Infra
2. Root cause: ** /dev/kvm device node not created because KVM driver failed to initialize on purwa-evk platform; CONFIG_KVM=y is enabled but hardware virtualization support is either unavailable or EL2 is locked down by firmware, preventing KVM from creating the device node at boot.
3. Possible fix: Skip KVM tests on purwa-evk in the LAVA job definition by adding platform-specific test exclusions for KVM_Infra, KVM_Driver, and KVM_EL2_DTB; investigate purwa-evk hardware specs and firmware configuration to determine if virtualization support can be enabled.
4. Detail analysis attachment: failed_case_job262795_6_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/262796

Failed test cases in LAVA job 262796 (SoC: qcs8300-ride).

  Case 1: Probe_Failure_Check — False Positive (Benign Firmware Load Failure)

1. Failed case: Probe_Failure_Check — False Positive (Benign Firmware Load Failure)
2. Root cause: The test detected a regulatory.db firmware load failure (error -2 = -ENOENT) from the cfg80211 subsystem during boot. This is a benign, expected failure on systems where the regulatory database is compiled into the kernel rather than loaded as an external firmware file. WiFi functionality is confirmed working (WiFi_Firmware_Driver and WiFi_OnOff tests both passed), and the ath11k WiFi driver successfully initialized and loaded its own firmware.
3. Possible fix: Suppress this specific firmware load error pattern in the Probe_Failure_Check test logic. The test should exclude regulatory.db firmware load failures when: (1) the error is -ENOENT (file not found), (2) cfg80211 has compiled-in X.509 certificates loaded (indicating built-in regulatory support), and (3) WiFi driver probe succeeds. This is not a kernel regression introduced by PR QCLINUX: qcom.config: Make Teo governor as default for CPUidle #1320 (which only changes CPUidle governor config).
4. Detail analysis attachment: failed_case_job262796_1_detailed.md

  Case 2: KVM_Driver — /dev/kvm device node not created

1. Failed case: KVM_Driver — /dev/kvm device node not created
2. Root cause: KVM driver failed to initialize on QCS8300 (Monaco) platform; CONFIG_KVM=y is enabled but KVM subsystem produced no kernel log messages and /dev/kvm was never created, indicating silent initialization failure likely due to missing ARM virtualization hardware support (VHE/EL2) or platform-specific KVM incompatibility on this SoC.
3. Possible fix: Verify that QCS8300 (Monaco) SoC supports ARM virtualization extensions (VHE/EL2) and that the bootloader/firmware boots the kernel at EL2; if hardware supports virtualization, check for missing device tree properties (e.g., psci node with virtualization support) or platform-specific KVM enablement requirements; if QCS8300 does not support KVM, mark these tests as SKIP for this platform rather than FAIL.
4. Detail analysis attachment: failed_case_job262796_2_detailed.md

  Case 3: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM device node /dev/kvm not created because the QCS8300 Ride platform boots in EL1 (non-virtualized mode) rather than EL2 (hypervisor mode), preventing KVM ARM initialization despite CONFIG_KVM being enabled in the kernel configuration.
3. Possible fix: This is a pre-existing platform/firmware limitation, not a PR-introduced regression. The QCS8300 Ride board firmware does not boot Linux at EL2, which is required for KVM ARM support. To enable KVM: (1) update the bootloader/firmware to boot Linux at EL2 instead of EL1, or (2) if the platform does not support EL2 boot, mark KVM tests as expected-to-fail for this SoC in the CI configuration.
4. Detail analysis attachment: failed_case_job262796_3_detailed.md

  Case 4: KVM Infrastructure Test Failure — /dev/kvm device node not created

1. Failed case: KVM Infrastructure Test Failure — /dev/kvm device node not created
2. Root cause: KVM subsystem failed to initialize during kernel boot despite CONFIG_KVM being enabled; no KVM initialization messages appear in boot log, indicating either the QCS8300 platform is not booting at EL2 (hypervisor exception level) or hardware virtualization support is disabled/unavailable on this SoC/firmware configuration.
3. Possible fix: Verify the QCS8300 platform boots at EL2 by checking bootloader configuration and firmware settings; if the platform does not support EL2/virtualization, mark KVM tests as "not applicable" for this SoC in the LAVA test suite; if EL2 is expected, enable KVM debug logging (kvm-arm.mode=debug) and check for silent initialization failures in early boot.
4. Detail analysis attachment: failed_case_job262796_4_detailed.md

  Case 5: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test runner marked the test definition as failed because individual test cases within the suite failed (Probe_Failure_Check due to regulatory.db firmware load error, and three KVM tests due to /dev/kvm not being available on qcs8300-ride platform), but the kernel booted and ran successfully without crashes.
3. Possible fix: The failures are not PR-introduced regressions. The PR only changes CPUidle governor config (menu→teo) which does not affect KVM device node creation or regulatory firmware loading. These are pre-existing platform/configuration issues: (1) Add regulatory.db firmware file to rootfs or suppress this benign warning in Probe_Failure_Check test; (2) KVM failures are expected on qcs8300-ride if KVM is not supported/enabled on this SoC - either enable KVM support or skip KVM tests on this platform.
4. Detail analysis attachment: failed_case_job262796_5_detailed.md